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Abstract 

A central challenge in computer science and knowledge representation is the inte- 
gration of conceptual frameworks for continuous and discrete change, as exemplified 
by the theory of differential equations and real analysis on the one hand, and the 
theory of programming languages on the other. 

We take the first steps towards such an integrated theory by presenting a recipe for 
the construction of continuous programming languages — languages in which state 
dynamics can be described by differential equations. The basic idea is to start with 
an untimed language and extend it uniformly over dense (real) time. 

We present a concrete mathematical model and language (the Hybrid concurrent 
constraint programming model, Hybrid cc) instantiating these ideas. The language 
is intended to be used for modeling and programming hybrid systems. The language 
is declarative — programs can be understood as formulas that place constraints 
on the (temporal) evolution of the system, with parallel composition regarded as 
conjunction. It is expressive — it allows the definition of continuous versions of the 
preemption control constructs. 

The language is obtained by extending the general-purpose computational formalism 
of (default) concurrent constraint programming (Default cc) with a single temporal 
construct, called hence — hence A is read as asserting that A holds continuously 
beyond the current instant. Various patterns of temporal activity can be generated 
from this single construct by use of the other combinators in Default cc. We provide 
a precise operational semantics according to which execution alternates between (i) 
points at which discontinuous change can occur, and (ii) open intervals in which 
the state of the system changes continuously. Transitions from a state of continuous 
evolution are triggered when some condition starts or stops holding. We show that 
the denotational semantics is correct for reasoning about the operational semantics, 
through an adequacy theorem. 
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1 Introduction 



A core divide lies at the heart of computing. Most of the physical sciences, con- 
cerned with the conceptual analysis of everyday phenomena, have relied on the 
development of continuous mathematics. Quantities of interest are represented 
as functions over the reals, and their variation over time described by systems 
of differential equations. The work in this area relies on three centuries of con- 
tinuous development in classical mathematics. However, traditional computer 
science deals with discrete state spaces: finite variables holding concrete values 
drawn from discrete domains, such as the integers, or set-theoretic structures. 
Change arises through the discrete change of values for variables; the current 
state of a system may have no structural relationship to the past - for instance, 
there is no analog for the mean value theorem. The only notions of continuity 
have to do with formalizing the intuitive meaning of recursion as the taking 
of limits in some "information" space. There have not been well-developed 
notions of continuous programming languages, with a concomitant theory of 
continuous control structures. 



1.1 Hybrid systems 

A fundamental need to reconcile these two approaches arises in hybrid sys- 
tems, the natural continuous extensions of reactive systems [25,7,22], Reac- 
tive systems react with their environment at a rate controlled by the envi- 
ronment. Execution in such a system proceeds as bursts of activity. In each 
phase, the environment stimulates the system with an input, obtains a re- 
sponse within a bounded amount of time, and may then be dormant for an 
arbitrary period of time before initiating the next burst. Thus, the notion 
of time in such systems is discrete, i.e. time is accurately modeled by the 
natural numbers. In [7] determinate synchronous programming is identified 
as the appropriate paradigm for the modeling and programming of such sys- 
tems. Examples of synchronous programming languages are CSML, Esterel. 
Lustre, SCCS, Signal, Statecharts and Timed default concurrent constraint 
programming [4,10,23,18,24,12,39,11,45,22]. This methodology has been suc- 
cessfully applied to actual systems — for example, telecommunication appli- 
cations [31,30,40], communication protocols [9] and robotics [13]. 

Continuous or analog systems are those in which the system has the potential 
of evolving autonomously and continuously. The description of this behavior is 
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usually in the form of differential equations that arise naturally in the descrip- 
tion and modeling of the behavior of mechanical and physical components. For 
example, in the animation language TBAG [16] ? the motion of a ball under 
the influence of various forces is described directly by the equations induced 
by the laws of motion. 

In contrast to reactive systems, the appropriate notion of time in such systems 
is dense, i.e. an accurate modeling of time requires a. dense domain such as 
the rationals or the reals. However, the ideas of synchronous programming are 
still relevant to dense time domains [5]. 

Complex applications typically require the combination of both these ideas. 
Consider for example, virtual prototyping — the substitution of computer 
models for physical products, processes, and systems. Intuitively, the aim of 
virtual prototyping is to make extensive use of software models to reduce 
the number of physical prototypes that must be constructed. Examples in- 
clude simulators for aspects of electronic or telecommunications systems, and 
visualizations of mechanical, chemical or civil systems. Consider a concrete 
example — the paper path of a simple photocopier, see Figure 1. 



Paper Motion 



Reg. Clutch 
R3 



Paper Tray 



Acq Roll 



Rl 



10 




R4 Vacuum Belt 



5 Fuser roll 
R6 



55 



80 



85 



Exit 



Image Transfer I 
Mechanism 



Fig. 1. A simple photocopier 

In this photocopier, paper is loaded in a paper tray at the left of the machine. 
When a signal is received, the acquisition roll is lowered onto the paper and 
pulls the top sheet of paper towards the first set of rollers (Rl). After the paper 
is grasped by the first set of rollers, the acquisition roll is lifted, and the rollers 
pull the paper forward, till it reaches the registration clutch (R3). This starts 
at a precise moment for perfect alignment, and the image is transferred onto 
the paper by the image transfer mechanism. The vacuum belt (5) transports 
it to the fuser roll (R6), from where it exits. 

The photocopier above has a collection of components with continuous be- 
havior, for example, the rollers and belts. However, the control program — 
the program that controls the actions in the physical system above — of the 
photocopier is a reactive system. Therefore, the modeling language should be 
able to describe the interaction of the control program and the continuous 
components — thus, the modeling language has to fall in the framework of 
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hybrid systems [6,42.35.17] 



1.2 The research program 

This paper is concerned with executable specification/programming languages 
for hybrid systems. Executability ensures that given a model of the system, it 
is possible to predict the behavior of the system when inputs are supplied. This 
would allow hybrid control programs to be written using the same notation 
as component models. If sensors and actuators coupling the language imple- 
mentation with the physical environment are provided then, in fact, it should 
be possible to use programs in this notation to drive physical mechanisms. 

The primary issues that arise in programming such systems are time-criticality, 
reliability and maintainability in the face of change. For example, in the realm 
of virtual prototyping, the models must be an accurate representation and 
rendering of objects; they must permit changes of components and must be 
amenable to reasoning about the actual underlying physical processes. 

The focus of this paper is the design and investigation of a paradigm, Hybrid 
Concurrent Constraint programming or Hybrid cc, for the modeling, program- 
ming and analysis of hybrid systems. We intend to establish the viability of the 
paradigm by subjecting it to the following tests. These criteria are motivated 
by the desirable properties expected by a "user" of the paradigm. 

- Is Hybrid cc declarative? Can programs be understood as formulas that place 
constraints on the (temporal) evolution of the system and be viewed as a 
declaration of facts in a (real-time) (temporal) logic [36,1]? 

This criterion can be viewed as a measure of the ease of use of the 
paradigm by systems engineers — people quite different in training and 
background from software engineers. Typically, systems engineers under- 
stand the physics of the system being designed or analyzed, and are used 
to mathematical or constraint-based formalisms (equational and algebraic 
models, transfer functions, differential equations) for expressing that knowl- 
edge. 

- Is Hybrid cc powerful enough to encompass extant special purpose languages 
in the hybrid genre — say for example, the animation language TBAG? 

This criterion can be viewed as one measure of the expressive power of 
Hybrid cc. One way to demonstrate that Hybrid cc satisfies this criterion 
would be to show that Hybrid cc can be used as the metalanguage for a 
semantics of the special purpose languages. 

- Does Hybrid cc support modularity, i.e. support for hierarchical construction 
of programs/specifications to aid in maintainability? 

This criterion can be viewed as a measure of the expressive power of 
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Hybrid cc from a programming language viewpoint and can be rephrased as: 
Are there enough combinators — ways of building programs — in Hybrid 
cc? 

- Does Hybrid cc specialize easily and usefully to particular domains? 

This criterion can be viewed as a measure of the utility of the insights 
gained by the research. One way to demonstrate this criterion would be 
design and implement a language in the Hybrid cc paradigm to program 
problems in a particular domain of hybrid systems. 

- Does the paradigm integrate smoothly with extant techniques/tools, for 
the specification, verification and reasoning about properties, including real 
time constraints, of hybrid systems? 

This criterion ensures that existing technology on the analysis of hybrid 
systems can be reused in the Hybrid cc paradigm. Thus, Hybrid cc must 
be amenable to (adapting) the methodology developed in the extensive re- 
search on reasoning about hybrid and real-time systems — for example, 
specification and verification of properties of hybrid systems [17,14], quali- 
tative reasoning about physical systems [50], and envisionment of qualitative 
states [34]. 

From a designer point of view, we intend to achieve the above criterion by- 
ensuring that Hybrid cc has good formal properties. Concretely, the technical 
questions addressed by research program will include the following: 

- Axiomatization of the notion of a continuous constraint system to describe 
the continuous evolution of system trajectories. Design of Hybrid constraint 
languages — developed generically over continuous constraint systems. 2 

- Description of formal operational, denotational and logical semantics. 

- Characterization of combinators definable in Hybrid cc and comparison of 
expressive power with synchronous programming languages. 

- Compilation of Hybrid cc programs to hybrid automata and integration with 
existing verification techniques and tools. Applications of semantics based 
analysis (such as abstract interpretation and constraint based program anal- 
ysis) to analysis of Hybrid cc programs. 

- Typing and type checking of Hybrid cc programs — types as succinct repre- 
sentations of the interface presented by the component — this interface will 
identify the assumptions expected of the environment in which the compo- 
nent will work, and the guarantees provided by the component. 

- Modeling of a real problem (such as the paperpath of a photocopier above) 
and analysis using the methods developed in the above items. 



2 Similar to the way concurrent constraint programming is developed generically 
over a notion of a constraint system. 



1.3 What have we done? 



This paper describes and studies some of the aspects of Hybrid cc hybrid 

concurrent constraint programming. 

- We introduce the notion of a continuous constraint system to describe the 
continuous evolution of system trajectories. 

- Hybrid constraint languages — developed generically over continuous con- 
straint systems — are obtained by adding a single temporal construct , called 
hence. Intuitively, a formula hence A is read as asserting that A holds con- 
tinuously beyond the current instant. 

- We describe operational and denotational semantics, and show that the de- 
notational semantics is correct for reasoning about the operational seman- 
tics. The operational semantics has been implemented to yield an interpreter 
for Hybrid cc. 

- We show that continuous variants of preemption-based control constructs 
and multiform timing constructs are definable in Hybrid cc. 

- We describe a few programming examples, and the trace of an interpreter 
on these examples. These examples illustrate the s}'nthesis, in Hybrid cc, of 
intuitions from concurrent constraint programming, synchronous program- 
ming and extant models of hybrid systems. 



1.4 Organization of paper 



We proceed as follows. First, we review the idea of compositional modeling — 
our analysis is motivated by the synchronous programming paradigm. Next, 
we describe the basic computational intuitions underlying Hybrid cc. Then, we 
begin our formal development. We start off with a review of constraint sys- 
tems and our earlier work on Default cc. Next, we introduce Hybrid cc via its 
denotational semantics — this denotational model formalizes the "programs 
as constraints" idea and associates with each process the collection of its ob 
servations. The denotational model of Hybrid cc is an "extension" of Default 
cc over continuous time. This extension proceeds in two stages. First, we in- 
troduce the notion of a continuous constraint system — a real-time extension 
of constraint systems — to describe the continuous evolution of system tra- 
jectories. Next, we extend the Default cc model of processes over continuous 
time to describe Hybrid cc processes. We illustrate the language and the de- 
notational semantics by describing a variety of combinators that are definable 
in the language. We then describe the operational semantics; we also describe 
an interpreter we have built that realizes the operational semantics and show 
that the denotational semantics is correct for reasoning about the operational 
semantics. We describe a couple of programming examples, and show traces 
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of our interpreter on these examples. We conclude with a discussion of the 
issues that remain to be addressed. 



1.5 Compositional modeling revisited 



Out of considerations of reuse, it seems clear that models of composite sys- 
tems should be built up from models of the components, and that models' of 
components should reflect their physics, without reflecting any pre-compiled 
knowledge of the configuration in which they will be used (the "no function in 
structure principle", [15]). Concretely, this implies that the modeling language 
must be expressive enough to modularly describe and support extant con- 
trol architectures and techniques for compositional design of hybrid systems, 
see for example [27,29,41]. From a programming language standpoint, these 
modularity concerns are addressed by the analysis underlying synchronous 
programming languages [4,22,10,23,1S,24,12,45]," (adapted to dense discrete 
domains in [5]); this analysis leads to the following demands on the modeling 
language. 

Consider a simple protocol that implements the controller of a paper-tray of a 
photo-copier. The controller switches the paper tray motor on and off, always 
trying to keep the top of the stack of paper next to the feeder. There are two 
sensors, P and E, which are set to 1 when the height of the paper is OK. 
Whenever the paper level falls, i.e. one of the sensors becomes zero, the motor 
is activated to push up the paper stack. This protocol can be construed as a 
finite state machine Perfect P with two states as in Figure 1. This finite state 
machine captures the structure of the implementation of this protocol in a 
sequential language. 




Fig. 2. Automaton for a perfect paper-tray 

However, sequential programs (and hence the automaton above) do not have 
parallel structure; consequently, small and succinct changes in the specification 
can lead to global changes in the automaton [40]. For example, let us say that 
we want the controller to also be aware of the fact that the sensors may be 
broken. In this case, it should stop the motor after a certain delay, in order 
to prevent it from damaging the copier. An automaton for this protocol is as 
in Figure 2. This automaton is merely a representation of the structure of the 
implementation of this protocol in a sequential language. 

Note that there is no structural relationship between the two automata. This 
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Fig. 3. Automaton for a paper-tray with failure modes 



makes the maintenance of such code through changes in requirements and 
specification an arduous task. Logical concurrency and preemption allow us 
to achieve modularity. In the above example, with a preemption combinator 
and parallel composition (written as | |), the program for the second paper- 
tray controller is written in terms of Perf ectP as follows: 

[do 

Perf ectp I I Set-Sensor-broken 

watching sensor-broken] 

The do ... watching statement terminates the program PerfectP when the 
signal "sensor-broken" is emitted. The procedure Set-sensor-broken is re- 
sponsible for emitting the signal "sensor- broken". 

Intuitively, logical concurrency /parallelism plays a role in determinate reac- 
tive system programming analogous to the role of procedural abstraction in 
sequential programming — the role of matching program structure to the 
structure of the solution to the problem at hand. Furthermore, preemption — 
the ability to stop a process in its tracks — is a fundamental programming 
tool for such systems [S]; note the use of the watchdog preemption in the above 
example. Examples of preemption include interrupts, process suspension and 
process abortion. Consequently, we demand that preemption constructs have 
the same status as concurrency. Finally, the language should allow the ex- 
pression of multiple notions of logical time — for example, in the photocopier 
the notion of time relevant to the paper tray is (occurrences of) the event of 
removing paper from the tray; the notion of time relevant to the acquisition 
roll is determined by the rotation rate of the roller; the notion of time of the 
image transfer mechanism is the rate of rotation of the belt etc. 

Thus, we demand that Hybrid cc be an algebra of processes, that includes 
concurrency, hiding, preemption and multiform time. 
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Intuitively, hence might appear to be a very specialized construct, since it 
requires repetition of the same program at every subsequent time instant. 
However, hence can combine in very powerful ways with positive and negative 
ask operations to yield rich patterns of temporal evolution. The key idea is that 
negative asks allow the instantaneous preemption 3 of a program — hence, a 
program hence (if a else A) will in fact not execute A at all those time 
instants at which a is true. 

Let us consider some concrete examples. Let always .4 = (.4, hence A). Sup- 
pose that we require that a program A be executed at every time point un- 
til a is true. This can be expressed as new A' in (always (if X else A, 
if a then always A')). Intuitively, at every time point, the condition A" is 
checked. Unless it holds, A is executed. A" is local — the only way it can 
be generated is by the other program (if a then always A), which, in fact 
generates X continuously if it generates it at all. Thus, a copy of A is exe- 
cuted at each time point until a is detected. Similarly, to execute A precisely 
at the first time instant (assuming there is one) at which a holds, execute: 
new A in always (if A else if a then A, if a then hence A). 

While conceptually simple to understand, hence .4 requires the execution of 
A at every subsequent real time instant. Such a powerful combinator may 
seem impossible to implement computationally. For example, it may be possi- 
ble to express programs of the form new T in (init(J = 0), hence dot(T) = 
1, hence if rational(T) then A) which require the execution of A at every 
rational q > 0. Such programs are not implementable, because rationals (ir- 
rationals) are everywhere dense as a subset of the reals. We show that in 
fact Hybrid cc is computationally realizable. The basic intuition we exploit 
to handle the first problem is that most physical systems change "slowly". 

3 Instantaneous preemption allows a program to be aborted immediately, rather 
than after executing a little longer like the control-C of Unix. See [8]. 
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with points of discontinuous change, followed by periods of continuous evolu- 
tion. Technically, we introduce a stability condition for continuous constraint, 
system that guarantees that for every pair of constraints a and b there is a 
neighborhood around 0 in which a entails b either everywhere or nowhere. 
This rules out constraints such as rational(T). 

With these restrictions, computation in Hybrid cc may be thought of as pro- 
gressing in phases of computation — alternating between point phases and 
open interval phases. Computation at a time point establishes the constraint 
in effect at that instant, and sets up the program to execute subsequently. 
Computation in the succeeding open interval determines the length of the in- 
terval r and the constraint whose continuous evolution over (0,r) describes 
the state of the system over (0, r). 

One further problem remains, arising from the interaction of existentials (new 
variable creation) and continuous evolution of the system. For example, we 
may have programs of the form hence (new T in . . .) which seem to require 
the creation of a copy of the new variable T for every real instant in the con- 
tinuous evolution in (0, . . .). To handle this problem, we restrict the variables 
on which existential quantification can be performed to those variables for 
which one copy of the variable suffices for a continuous evolution. Technically, 
we emulate the flexible existential quantification of temporal logic, by making 
3 a' commute with the temporal constructions in the ccs. 



3 Background 



We first review Default cc [45], an extension of cc programming. For technical 
convenience, the presentation of constraint systems here is a slight variation 
of an earlier published presentation [47]. 4 



3 A Constraint systems. 



A constraint system V is a system of partial information, consisting of a set of 
primitive constraints (first-order formulas) or tokens D, closed under conjunc- 
tion and existential quantification, and an inference relation (logical entail- 
ment) h that relates tokens to tokens. We use a, 6, c, . . . to range over tokens. 



[45] extends the conference version in POPL 95 with hiding. 
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h induces through symmetric closure the logical equivalence, Formally. 

Definition 1 A constraint system is a structure (£>, K Var, {3 X | A" G Var}) 
sue/* £/iaf: 

- 25 closed under conjunction (A); hC D x D satisfies: 
•aha 

• a I- a' and a' A a" \- b implies that a A a" \- b 

• a A 6 h a and a A b h b 

• a h and a h 6 2 implies that a h- b\ A b 2 . 

- Var 25 an infinite set of variables, 5uc/i /7ia2 for each variable X e Var, 
3a' : D — » Z> 25 an operation satisfying usual laws on existentials: 

- a h 3xa 

• 3 a- (a A 3 x b) % 3 A -a A 3 x b 

• 3x3ya % 3 r 3 x a 

• a I- 6 implies 3 x a h 3 A -6. 

- h 25 decidable. 

The last condition is necessary to have an effective operational semantics. 

A constraint is an entailment closed subset of I?. For any set of tokens S, we 
let 5 stand for the constraint {a e D \ 3{a u . . . ,a*} C 5. a x A . . . A a k ha}. 
For any token a, a is just the constraint {a}. 

The set of constraints, written \D\, ordered by inclusion(C), forms a complete 
algebraic lattice with least upper bounds induced by A, least element true = 
{a | V6 e D. b h a} and greatest element false = D. Reverse inclusion is 
written D. 3, h lift to operations on constraints. Examples of such systems are 
the system Herbrand (underlying logic programming), FD [26](finite domains), 
and Gentzen [46]. 

Example 2 The Herbrand constraint system. Let L be a first-order lan- 
guage L with equality. The tokens of the constraint system are the atomic 
propositions. Entailment is specified by Clark's Equality Theory, which in- 
clude the usual entailment relations that one expects from equality. Thus, for 
example, f(X 9 Y) = f{A,g{B,C)) must entail A" = A and Y = g(B,C). 

Example 3 The FD constraint system. Variables are assumed to range 
over finite domains. In addition to tokens representing equality of variables, 
there are tokens that that restrict the range of a variable to some finite set. 

Example 4 The Gentzen constraint system. For real-time computation 
we have found the simple constraint system (G) to be very useful. The primitive 
tokens a, of Gentzen are atomic propositions A', Y, Z . . .. These can be thought 
of as signals in a computing framework. The entailment relation is trivial, i.e. 
ai A . . . Aa n \- g a iff a = a, for some i. Finally 3a' {g>i A . . . Aa n ) = 6 a A . . . A6 n 
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where 6, = a, if a , ^ X and 6, = true otherwi 



lse. 



In the rest of this section we will assume that we are working in some constraint 
system (D, KVar, {3 X | A" € Var}). We will let a, b, . . . range over D. We use 
u, v, w. . . to range over constraints. 



3.2 Default cc 



We provide here a brief review of our earlier work on Default cc. More details 
and motivation for the definitions can be found in [45], 

Denotational semantics of Default cc. We extend the idea of cc, that the 
denotation of a process consists of all observations. The critical question is: 
what is an observation? Observe for each agent A those stores u in which they 
are quiescent 5 , given the guess v about the final result. Note that the guess v 
must always be stronger than u — it must contain at least the information on 
which A is being tested for quiescence. The intended interpretation is: if the 
guess v is used to resolve defaults, then executing A in u does not produce 
any information not entailed by u. 

Definition 5 (Default cc Observations) 
DObs = {(u,v) e \D\ x \D\ | v D u}. 

To describe processes and the denotation of combinators, we need some no- 
tation - for a set S of constraints, and constraint v, (S,v) stands for the set 
{{u, v ) I u e S}. HS stands for the greatest lower bound of 5. 

A process is a collection of observations that satisfy two "closure" conditions: 

- Local determinacy — the idea is that once a guess is made, everv process 
behaves like a determinate and monotone (with respect to the partial order 
on constraints) program. 

- Guess convergence — we will only make those guesses under which a process 
can actually quiesce. This is needed to eliminate spurious guesses, which 
could never be correct as they are not quiescent stores. 

Definition 6 (Process) A process Z is a subset o/DObs satisfying: 

- (nS,v) e Z i/S ^ 0 and (S,v) C Z 

- (v,v) e Z if(u,v) € Z. 



5 A quiescent store u is one in which executing A will not result in the generation 
of any more information. 
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Note that under this definition. Default cc processes are closed under arbitrary 
intersections. 

The denotational semantics of the combinators can now be described. The 
information about the guess v is not needed for the tell or ask combinators. 
An observation of a parallel composition must be a quiescent point of both 
programs simultaneously note that a guess v for A,B is propagated down 
as the guess for A and B. Note the crucial use of the guess/default in the 
definition for if a else A — the guess is used to determine if A is initiated. 

V[A,B]^V{A]nV[B} 

PW={(u,«) € DObs | a € u} 
V[if a then A] = {(«, v) 6 DObs | aev=>{u,v)e PffAJ, 

a G u => («,v) € P[XJ} 
P[if a else A\ = {(ti, v) 6 DObs | a £ v => (u, v ) G VIA]} 

Our presentation of Default cc here does not have recursion as recursion in 
Hybrid cc is handled by guarded recursion over time. 



Hiding, Intuitively, the process new A* in A is supposed to behave like 
the process A[Y/X], where Y is some new variable distinct from any variable 
occurring in the environment. Somewhat surprisingly, the definition of hiding 
in the model is subtle and involved. The reason is that the union of two 
processes is not a process. Therefore, the "internal choice" (or "blind" choice) 
combinator A n B of Hoare 6 is not expressible in the model. 

Hiding, can, however, mimic internal choice, in the presence of defaults. Con- 
sider the process A = (if X = 1 else (Y = 1,A' = 2), if X = 2 else (Z = 
1,X = 1)). These are two conflicting defaults. The process contains in its 
denotation the observations {(Y = 1,A" = 2),(V = 1,Z = 1,A* = 2)), and 
((Z = 1»A = 1),(V = l y Z — 1, A" = 1)). However, no information about A" 
can appear in the denotation of the process new A" in A. Consequently, one 
would expect new A in A to exhibit the observations (Y = l,(y r =l,Z = l)) 
and (Z = 1, (Y = 1, Z = 1)). If new A' in A is to be a process, however, it 
must be locally determinate: it must also exhibit the gib of these two obser- 
vations, namely (true, (Y = 1,Z = 1)). However, it cannot do that, since 
it must either produce Y = 1 or produce Z = 1. Thus, the straightforward 
definition of new A" in A cannot be a process. 

6 A n B behaves like either A or 2?, and the choice cannot be influenced by the 
environment. 
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Our pathway for describing the denotational semantics of hiding and resolving 
the above problems is as follows — Let Z be any process, we want to define 
the process new.\-Z. 

- Recall that the variable X is local to Z. Thus, default assumptions (guesses) 
about the variable X must be reasonable, i.e. there must be some evolution 
of Z that generates the default assumptions on A' — restricting Z to such 
defaults gives us a subset of Z, call it Z x . 

- Identify the "maximal determinate subprocess" of Z x — call it Z 2 . This 
eliminates the possibility of locally indeterminate processes, as was the case 
above. 

- Finally, we follow intuitions from cc to obtain the definition. Consider the 
behavior of new X in A on an input a. a may constrain X; however this 
A* is the "external" X which the process must not see. Hence, to obtain 
the behavior on a, we should observe the behavior on 3 x a. However, the 
result, say 6, may constrain X, and this X is the "internal" A'. Therefore, 
the result seen by the environment must be a U 3 x b. 

Given a process Z, we build the denotation new x Z in three stages, corre- 
sponding to the intuitive steps outlined above. First some notation. If S is a 
set of constraints, define 3A.5 = {u 6 \D\ \ 3u' € S.3 x .u = 3 x .u'}. For any 
process Z and {v,v) e Z, let Z v = {u € \D\ \ (u,v) € Z}. 



- Define Z x ± \J{(Z v ,v) C Z \ Vu € Z v , u D 3 x v => u = v}. 

- Define Z 2 I \J{(Z v ,v) C Z, | W € \D\,(v',v') e Z u 3 x v = 3 x v' ^ 
3 X Z V = 3 X Z V >). 

- Now new A -Z ± \J{(S,v) C DObs | 3v'[(v',v') € Z 2 ,3 x v = 3 x v',3 x S = 
3 X Z V >]}. 

So, we have: PJnew X in A] = new A --p|v4j 

Definition 7 A process Z is X -determinate if Z x = Z 2 , where Z U Z 2 are as 
above. 

With the above definitions, we can work out the denotation of any Default cc 
process. Here we consider two interesting examples. 

Example 8 

V[ifa else a] = {(u,v) e DObs | a G v} 

This is an example of a default theory which does not have any extensions 
[44]. However, it does provide some information, it says that the quiescent 
points must be greater than a, and it is necessary to keep this information to 
get a compositional semantics. 
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Example 9 

V{ifa then 6, if a else 6J = 

{{u,v) e DObs | b e v.. {(a 0 v) V (a G u)) => 6<E ti} 

This program is "almost" like "if a then 6 else V\ and illustrates the ba- 
sic difference between positive and negative information. In most semantics, 
one would expect it to be identical to the program 6. However the fact that 
b is produced by a default makes it different — this is demonstrated by 
running both the programs b and if a then 6, if a else b in parallel with 
if b then a. 6, if b then a produces a U b on true, while if a then 6, if a else 6, 
if b then a produces no output. On the other hand it is not the same as 
if a then 6, if -»a then b — in this program to produce 6, either a or ->a must 
be present in the store, whereas the original program will produce b if nothing 
is present in the store. 



Input-output behavior. Given a process Z, we can define its input-output 
behavior as follows — 

Z{a) = {b e D | b h a, (6, b) € Z, (Vi/)(u, b) € Z, a € u u = 6} 

Thus the output on a is any guess 6 such that there is no quiescent point 
between a and b — once a is added to the store, under the final assumption 
6, Z will quiesce only on 6. Z may be extended to constraints. 

Remark 10 Note the role of observations of (u,t>) with n ^ v. Such obser- 
vations play a crucial role in the determination of the input-output behavior 
of the process. However, any output v will perforce occur in the denotation of 
the process as (v,v). 

Example 11 In the program if a else a, there is no possible output above 
the input true. Thus running such a program would produce an error. On 
the other hand, there can be multiple outputs — both a and 6 are possible 
outputs on input true for the program if a else 6, if b else a. 

This leads us to the definition of determinacy. 

Definition 12 A process Z is called determinate if its input-output behavior 
is a function with domain D. 

Clearly, a is determinate for all a, and it can be shown that if A is determinate, 
then if a then A and new A' in A are determinate. However, if a else ,4 and 
A, B may be indeterminate even if A and B are determinate. 
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In [45], we provide an algorithm to detect when any program is indeterminate 
— we briefly sketch the algorithm later in the section. This semantic notion 
of indeterminacy captures the essence of the "causality cycles" in imperative 
synchronous programming languages. 

Note the if Z is determinate, then Z is A'-determinate for all variables Y 
([45]). 



Operational semantics. A configuration T is a multiset of programs — 
to be thought of as the parallel composition of the programs. a(F) is the 
conjunction of the tokens in the tell agents in T. We define binary transition 
relations — > a on configurations; thus, the transition relation is indexed by 
the "guessed output token" o that will be used to evaluate defaults. 

a 1/6 

1', if 6 else B — > a T,B 

The other transition rules are as in cc — thus reinforcing the intuition that 
given a guess, a Default cc program essentially becomes a cc program. 

a(T) h b 

V, if b then B — > a T,B 

T, new X in A — T, A[Y/X] (Y not free in A, T) 
T,(A,B) —* a T,A,B 

Execution of an program A corresponds to finding a terminal configuration T 
such that the "guessed output constraint" is actually achieved — see remark 10 

3a eD r^;p^, a(r')^a 
r — ► r 

The output of the program is 3- a where Y are the new variables in P in- 
troduced by the operational semantics. The transition relation can easily be 
extended to constraints instead of tokens — indeed, this is the form which we 
use to show its equivalence to the denotational semantics. 



Correspondence theorems. We can now show that this semantics cor- 
responds to the denotational semantics closely. Define from the operational 
semantics 

0{A} = {{u.v) e DObs I (3v')(A,u) —+- v , A' = 3-<r(A%v = 3-v', 

(A,v) — >' v , A" 7^ t „,i> = 3-v',v' = a(A")} 
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defines the set of observations that can be made from the transition 
relation — recall that an observation consisted of a quiescent store, together 
with the guess about the final result. So (u,v) € 0[[.4J. if under guess v. u 
is a quiescent point, and v is itself a possible quiescent point. Note that the 
actual guess used is v', which contains in addition to v information on the new 
variables introduced in the derivation — this information is eliminated later 
by existential quantification. The following lemma shows that this intuition 
about observations is correct. 

Lemma 13 

Olal = Vla] 
OlA,B] = OlA]nOlBl 

Ofif a then A] = {(u,v) 6 DObs | a <= v =s> (v,v) <E 0\A\, 

a€u (u,v) € 0{A}} 
a else ^1 = {(", v) e DObs | a £ v =j> (u, v) e 0{A\] 
Ofnew X in A\ = new x e>f,4j, if 0(Aj is X - determinate 

PROOF. The proof follows extant proofs [47,32] for languages in the cc 
paradigm, and is presented in the appendix A. 

Now we can show the following theorem. We say that P satisfies the X- 
determinacy condition if whenever new A' in .4 is a subprogram of P then 
0{A} is A'-determinate. ' " 

^|pj rem 14 ^ P satis £ es the X-determinacy condition for all X, V{P] = 



PROOF. A simple structural induction using the above lemma 13 yields the 
required result. 



Determinacy detection. The above theorem allows us to use the opera- 
tional semantics for determinacy detection. Let P be a program. The basic idea 
is simple — use the operational semantics to check that (Va) [|0|[PJ(a)| = 1]. 
Notice that there is a quantification on a, and implicitly, one on guessed con- 
straints. Our earlier work [45] shows that it suffices to consider only a carefullv 
chosen finite set for these. 
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4 Hybrid cc — Language and Denotational Semant 



ICS 



Hybnd cc is intended to be a language for describing hybrid systems. Recall 
that a run of a hybrid system consists of an alternating sequence of points and 
open intervals — open intervals of continuous evolution connected by points 
of discrete change where discontinuities can occur. 

In this section, we describe Hybrid cc as an "extension" of Default cc over 
continuous time. This extension proceeds in two stages. First, we introduce the 
notion of a continuous constraint system — a real-time extension of constraint 
systems — to describe the continuous evolution of system trajectories alluded 
to above. Next, we extend the Default cc model of processes over continuous 
time to describe Hybrid cc processes. 



Notation. We use R+ for the set of non-negative real numbers, and will 
always mean K+ when we say "reals". We use standard notation for intervals 
of real numbers: (U,<2) for the open interval, [fl,<2) for the left closed and 
right open interval etc. We will use Int for the interior operator on intervals 
e.g Int([<M2]) = («,«). We will be working with partial functions on the 
reals— their domains will be initial segments of R+, i.e. fO,r) or [0,r] for some 
r € R + (where [0, 0) = 0). We use dom(/) for the domain of definition of /. 

We define restriction, f\I where 7 is a left closed interval, as (f\I)(t) = 
/(tl + t) where t + tl € dom(/),< € /, and the left endpoint of I is tl Given 
two partial functions / g we say / is a prefix of g if dom(/) C dom(g) and 
Y € dom (/)l/( < ) = 9(t)}. f is a proper prefix of g if / is a prefix of g and 

If / is a prefix of g, we define the function g after / as: (g after f)(t) = a(t + 
r), where dom(/) = [0,r) or [0,r]. This is extended to sets of partial functions 
S in a natural way: S after / J= {g after / | g € S,f is a prefix of g). We 
also define 5(0) = {^(0) | g € S). 

We use jti ir 2 for the first and second projections on pairs. Function composi- 
tion is indicated as fog. 



4-1 Continuous constraint systems 

Continuous constraint systems (ccs) augment constraint systems with the no- 
tion of a constraint holding continuously over a period of time. Intuitively, 
we proceed by adding structure to constraint systems to capture the informa- 
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We demand that (ID.h, Var ; {3 X \ X 6 Var}) is a sub-constraint svstem 
of(D, h, Var, {3 A - | A' € Var}). i.e. 

a . h b => b is an instantaneous token. (3) 

We denote the set of constraints associated with (/£>, h, Var, {3 A | A" G Var}) 
by \ID\; we denote the set of constraints associated with (D, K Var, {3 v | \" € 
Var}) by \D\ . As with any constraint system, \ID\ ( (resp. \D\) 'ordered bv 
inclusion is a complete algebraic lattice. We use U , v, . . . for instantaneous 
constraints and u, v.. . . for constraints of D. 

The constructions init, prev, cont commute with the logical connectives. 

init(a A b) » init(a) A init(6) init(3 A -«) « 3 A -(init(a)) 

prev(a A 6) « prev(a) A prev(fc) prev(3 A a) « 3 A (prev(a)) (4) 

cont(a A b) w cont(a) A cont(b) cont(3 A -a) » 3 A (cont(a)) 



Our final condition on h is that cont is idempotent. 

cont(cont(a)) ss cont(a) (5) 

We now describe the conditions on the relation h r . h r C D x ID — intuitively 
a h r b holds if the "integration" of the activity conditions in a with the initial 
conditions in a for length r yields 6. Indeed, h r induces integration operators 
I > for every r e M + are generated by H r : 



r 

I 



b L { a e ID I b h r a} 



All operations on tokens, f, A, 3 A , K, h r> prev, cont, init, described above 
lift to operations on the set of constraints in the constraint system induced bv 
(AK Var, {3 A I A* € Var}). 

Formally, we require the following conditions on H r , f T : It is not the case that 
for instantaneous tokens a that a h r a, unless of course r = 0. 

a l-o a ( 6 ) 

cont(a) maintains a for all r > 0. 



cont(a) h r a, if r > 0 



(7) 



Only the initial conditions, i.e. tokens of the form init(a), and the activity 
conditions, i.e. tokens of the form cont(a) matter on the left hand side. 

(Vc) [b h init(c) <s> b' h init(c), b h cont(c) <£> b' h cont(c)] 

(Vr >0) [bh rfl « b' h r a] " (S > 

For all r > 0, evolution is continuous, i.e. the left limit, the "value" at r and 
the right initial value all agree. 

b h r a <=> bh r prev(a) <=> b h r init(a) (9) 

Transitivity must be preserved on the left and the right, with respect to h: 

b' h b b h r a ' a ' h a" 

b 7 !^ 77 ( 10 ) 

The duration of integration is important, not when it was started. 

f[u A cont(b)] = y f[ v a cont(b)] = u> 
r s [uAcont(b)j = w 

To prevent constraints like rational(x), we require a neighborhood of 0, where 
K information is "stable". Define: 

aK6 = V<6(0,r)[a h, 6] 



al^ 6^V< 6 (0,r)[al/ t 6] 



Then we require: 

(Va eZ),5 6 7£>)(3r > 0) [(a K 6) v (a \f b)\ (12) 

Finally, we demand that / r commutes with 3 A -. 

r r 

j3xb = 3 x Jb ( 13 ) 

Definition 15 (Continuous Constraint System) A continuous constraint 

system (ccs) built on a constraint system (Base D , f- Basao , Var, {3 V I X € 

Var}) is a tuple (D,h, Var, {3* | A' e Var},{h r | r e K + }> satis- 
fies equations (1)-13. 
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Computability: The following are (sufficient) conditions to make the op- 
erational semantics effective. 

(i) r-,l- r! K,l/ r are decidable. 

(ii) For all tokens a and for all real numbers r, there exists a token b such 
that b = f a. 

(iii) For all tokens a, there are tokens b,d such that: 

b = {init(c) | a h init(c)}, d = {prev(c) | a h prev(c)} 

(iv) 

a, b j-y c r > Q 
3 x a, b h r c 

This condition says that existentially quantifiable variables cannot pass 
information across time. Together with condition 13, we can now prove 
that for all r > 0: 

J 3 x {a A cont(b)) = J 3 X (a) A 3 A -(cont(b)) 

This makes the existential quantification similar to the flexible quan- 
tification of temporal logic (see [36]). The combination of these conditions 
allows the implementor of the ccs to use one copy of the quantified vari- 
able for a given evolution of the ccs. 

Example 16 Let <Bas ez) , f- Basec , Var, {3 X | A' € Var}) be a constraint sys- 
tem. Then, the "free" ccs (£>, \~, Var, {3 X | X E Var}, {(- r | r e has h r 
defined as follows. 

b h 0 a iff b I- a 

b h r a if b h cont(a), r > 0 

We note that the integration operators f T b are quite trivial— intuitively, at 
r = 0, we get the instantaneous constraints in b, and for r > 0, we get the 
constraints a such that b h cont(a). In particular if r > 0, f b is indepen- 
dent of the instantaneous constraints in b — thus this ccs does not allow any 
"autonomous" evolution. 

Example 17 Let (Base/,, (- Baser) , 0, 0) be the constraint system whose basic 
tokens are formulas of the form dot(x,?n) = r or x = r, for x a symbol 
representing a real variable, rn a non-negative integer and r a real number. The 
inference relation K Bas9D is defined in the obvious way under the interpretation 
that dot(x,m) = r states that the mth derivative of x is r. 

Now, consider the ccs (D, h, 0, 0, {h r | r € fiS + }) generated as follows. The 
token cont(dot(x, m) = r) is interpreted as saying that that for all time t > 
0 the mth derivative of x is r; and the intention is that f r b is standard 
integration — a definite integral between endpoints 0 and r of the activity 
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conditions in b with initial conditions given by the tokens of form init(x = c). 
The token prev(.r = c) holds at time r if the left, limiting value of x is c. 

The inference relations are trivially decidable: the functions of time express- 
ible are exactly the polynomials. The h r , l/ r , K, l/ r relations are expressible 
parametrically in r; the only non-trivial computation involved is that of find- 
ing the smallest non-negative root of univariate polynomials (this can be done 
using numerical integration). 

Finally note that in this constraint system, under the intended interpretation, 
the real variables do not satisfy the computability condition (iv) — hence,' 
existential quantification of these is not allowed (indicated by Var = 0). 

Trace of a ccs. In the rest of this paper, we will take a more extensional 
view of the continuous evolution captured by a ccs — as functions from reals 
to the instantaneous constraints entailed at each point. To this end, we first 
characterize the functions that describe evolutions of a ccs. Let / : R+ — > \I£)\ 
be a partial function whose domain is a prefix of the positive reals, and whose 
range is instantaneous constraints. Let 

Active(/) = {a<=ID\ (Vr e dom(/) - {0}) [/(r) H a}} 
Definition 18 / : M+ \ID\ is a trace of the ccs if: 

T 

(Vr <E dom(/)) [ J [/(0) A cont(Active(/))] = f(r)) 

Thus, if / is a trace, the value of / at r is obtained by "integrating" the 
activity conditions of / — namely Active(/) — with initial conditions given 
by/(0). 



4-2 Denotational Model of Hybrid cc 



In the rest of this section we will assume that we are working in some con- 
tinuous constraint system (D, h, Var, {3 X | A* e Var},{l- r | r € 
built on a constraint system (Base c , h BaseD , Var, {3 A - | A' e Var}). Let 
DObs be the set of Default cc observations over the constraint system ID- 
DObs = {(u, v) € \ID\ x \ID\ \ vDu}. 



Observations. An observation, a run of the hybrid system, is a tracing 
of the system trajectory over time — open intervals of continuous evolution 
connected by points of discrete change. 
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What should an observation be? 

First, we intend the execution at every time instant to be modeled by the 
execution in Default cc. So observations are functions / : R + — > DObs, such 
that dom(/) = [0,r) or [O.r], a prefix of the non-negative reals. 

Secondly, we intend / to satisfy piecewise continuity — i.e. for any point in 
the interior of its domain, both components of the behavior of / on some open 
interval to the right arise from traces of the ccs. So, we demand that 

V* G dom(/)3e > 0 such that 7r x o f ^t, t + e), - 2 o / [[t, t + e) are ccs traces. 

For such an /, we can partition its domain into a (possibly infinite) alternating 
collection of points and open intervals, called the phases of the observation. 
Let t 6 Int(dom(/)) be such that there is no neighborhood [t — c, t + e) around 
<, such that tt 1 o f [[t - e, t + e) and tt 2 o / }[t - e, t + e) are traces of the ccs. 
This indicates that there is a "discontinuity" at <, and t is called a point phase 
of /. 0 is defined to be a point phase. Between two successive point phases, 
there is an (open) interval phase, where evolution proceeds via the ccs. 

Finally, we intend / to satisfy observability — i.e. the computation at any 
time point in dom(/) is a completed Default cc computation — a computation 
in which the guess was attained (recall remark 10). Thus, we want to ensure 
that if f(r) = (u,v), u ^ v, then r is in the terminal phase of /. Formally, we 
have two cases depending on whether the last phase is a point phase — (1) r 
is the least real at which tti o /, 7r 2 o / disagree - 

(Vr' < r)M/(r')) = * 2 (/(r'))] A ^(/(r)) * 7r 2 (/(r)) dom(/) = [0,r] 

or an interval phase (2) 7r x (/(r)) ^ 7r 2 (/(r)) and there is no minimal such r, 
then r must be in the last continuous phase - 

*i(f(r)) 7^ K2(f(r)) ttj o /h[r, oo), tt 2 o / ^r, oo) are ccs traces 

Definition 19 (Observations) HObs consists of functions f : & + — ► DObs 
suc/i dom(/) = 0, [O.r) or [0,r] /or sowe r 6 E + / satisfies piecewise 
continuity and observability. 

For / € HObs, define for every t € Int(dom(/)) U {0}, f{t+) = (Active^ o 
/K«,* + c)), Active(7r 2 o/h[f,f + €))), where e > 0 and 7Ti o / [[t. t + e), n 2 o 
f [[t, t + e) are traces of the ccs. Extend this to sets of observations by S(i + ) = 
{/(t + ) |/€5,<€dom(/)>. 



Processes. Analogous to Default cc, a process is a collection of observations. 
What closure properties should a process satisfy? 
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The first two closure conditions are quite general. The future cannot alter the 
past — thus, we demand prefix closure. Also, all effective computational sys- 
tems satisfy a limit closure property — if every proper prefix of an observation 
/ is in the process, then so is /. 

The other closure conditions arise from the fact that we intend the Hybrid cc 
processes to be Default cc generable. Thus, we intend the execution at every 
time instant to be modeled by the execution in Default cc. 

For all / in P (V* G dom(/)) (P after /h[0,t))(0) is a Default cc process. 

Furthermore, we intend the continuous behavior to be generated by Default 
cc processes. 

For all / in P (Vf G dom(/))(P after / ^(M])(0 + ) is a Default cc process. 

Definition 20 A process P is a non-empty, prefix closed subset of HObs 
satisfying limit closure and Default cc generability. 



Combinators. a, if a then .4, if a else A, (A, B) are inherited from De- 
fault cc and their denotations are induced by their Default cc definitions. We 
emphasize that here the tokens a are the instantaneous tokens of the ccs. e 
represents the function with empty domain. 

H[a] = {e} U {/ G HObs | /(0) = (u, t?), a G u) 
Wfif a then A} = {e} U {/ G HObs | /(0) = (u,v),a G u => / G H\A\, 

ae v^(v,v)eniA}} 

WPf a else A] = {e} U {/ G HObs | /(0) = («, v), a g v => / G «[AJ} 

Here when we say G W[A], we mean that the function / with dom(/) = 

•{0} and /(0) = (v,v) is in W[[A]]. new A' in A imposes the constraints of A, 
but hides the variable X from the other programs. Here the variable A" must be 
one for which 3a' is allowed in the ccs. Every observation / G 7Y[[new A' in AJ 
is induced by an observation g G WJAJ with the same domain and satisfying: 

- For every t G dom(/) = domfo), 3W/(0) = 3x*i(g{t)) and 3 x ir 2 (f(t)) = 
3x*2(g(t))- We write this as 3a'/ = 3xg> 

- For every t G dom(/), f(t) must equal the result of hiding A" in the Default 
cc process given by A at time t after history g\[0.t). A similar condition 
must hold for /(< + ). 
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Formally, 



W[new X in A] = 

{/ G HObs | 3<? € = 3 A '<7, 

(V< G dom(/)) [/(i) 6 newjc(M[Ajafter <^[0,0)(0)], 

(V« S Int(dom(/)) U {0}) [/(*+) G new x («|[,4j after g H0,i])(0+)]} 

We define the process new^Z by replacing H\A\ with Z in the right sides of 
the above definition. 

The definitions for hence is as expected — observations have to "satisfy" 
A everywhere after the first instant. Thus, intuitively, hence is a specialized 
form of "infinite" parallel composition of time shifted copies of A. 

W[hence A\ = {/ € HObs | (V* G dom(/) - {0}) [f\[t, oo) G H\A\]} 

Example 21 Consider the ccs of example 17. Consider the program P = 
init(x = 0), hence (dot(x, 1) = 1). The denotation of P consists of all ob- 
servations / that satisfy: tti(/(0)) I" init(x = 0), (Vr G dom(/)) [^(/(r)) h 
dot(x, 1) = 1]. From this, we deduce that for all r in an interval phase, (r', r") 
of /, we have ^i(/(r)) I- x = r + c, where init(x = c) holds in the prior point 
phase /(r'). In particular, for all r in the first interval phase of /, we have 
ni{f(r)) h x = r, Note however, that the semantics allows discontinuities in 
the value of x — thus at a point phase at r, init(x = r) does not necessarily 
hold. 

Equational laws. The above combinators satisfy the following equational 
laws. 

All combinators commute with parallel composition. 

hence (A, B) = hence A, hence B 
if a then (A, B) = if a then A, if a then B 
if a else (A, B) = if a else A, if a else B 
(new A" in A),B = new X in (A, S), if A r not free in B 

hence is idempotent: hence hence A = hence A. 
The order of conditions does not matter. 

if a else if b then A = if 6 then if a else A 
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where always A = A. hence A. 

Note that the above definition satisfies the caveat on first occurrences of a. 
For example, if a occurs for the first time throughout an open interval of 
continuous execution, then if a then hence x will make hence x be true in 
the entire open interval, so x will be true in the entire interval also. This will 
prevent the triggering of the ,4 in the interval. 
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Fig. 5. Time diagram for time A on a. 

Example 23 An important construct for reactive programs is multiform time 
— time A on a — it allows us to pass to a process only certain fractions of 
the real line. This construct is characteristic of synchronous programming 
languages — it enables us to write a process without referring to real time — 
we can write it with reference to the relevant notion of "logical time", which is 
the time at which a holds. The process A runs only during the times a holds, 
as shown in Fig. 5. Formally, we proceed as follows. 

Let / 6 HObs. Define dom a (/) = {t € dom(/) | a € * x {f(t))}. We say that / 
is a-good, if the set dom a (/), ordered by <, is composed of a series of left-closed 
right-open intervals, except the last which may be right closed. Intuitively, f 
is a-good if the logical time given by a can be substituted for real time, i.e. 
the set of reals at which a holds can be glued together to get a prefix of the 
reals. If / is a-good, we define / \ a as the pasting together of the phases of / 
in which a holds. Now, we can define: 

Tifftime A on a] = {/ € HObs | / \ a e H\A\J is a-good} 

This combinator satisfies the following equational laws. These laws can be 
used to remove occurrences of the combinator. 

time b on a = first a then b 
time (if b then B) on a = first a then if b then time B on a 
time (if b else B) on a = first a then if 6 else time B on a 

time (A,B) on a = (time A on a), (time B on a) 
time new x in A on a = new x in time A on a, (x not free in a) 
time (hence B) on a = first a then [hence (if a then time B on a)] 
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Proof are once again omitted, as they involve simple manipulations of defi- 
nitions. Only the last law needs some explanation — intuitively we start off 
a. copy of B each time a becomes true after the first occurrence of a (this is 
caused by the hence B). However, since B itself may have extended behavior 
over time, it should also be in the scope of a time B on a, since it should be 
active only when a is true. 

Now, we synthesize a variety of combinators using the above two combinators 
as building blocks. 

l \ ) 

A 



Time — ► 

Fig. 6. Time diagram for do A watching a. 

Example 24 The watchdog construct do A watching a is necessary for writ- 
ing reactive programs modularly. This construct allows us to terminate the 
execution of A whenever a occurs, as shown in Figure 6. For example, it is 
used in the billiards ball program later to terminate the movement of a ball 
when it falls into a pocket — it allows us to write the motion of a ball without 
referring to the pockets. 

Semantical^, an observation of do A watching a can arise as follows: 

- A is executed in the interval [0, r); a is not entailed in [0, r) and a is entailed 
at r. In this case the process A is aborted at instant r (in particular, A is 
not executed at r). There are no restrictions imposed by do A watching a 
in [r, oo). 

- A is executed in the interval [0, r]; a is not entailed in [0, r] and a is entailed 
in some open interval starting at r. In this case the process A is aborted 
after instant r. and there are no restrictions imposed by do A watching a 

in (r, oo). 

The following definition captures these intuitions. If in any trace, a is not true 
until some time /, then the portion upto t has to be derived from a trace in 
A. 



Hldo A watching aj = 

{/ € HObs | Let T = {t € IR+ | Vr 6 dom(/), r<t^a£ 7r 2 (/(r))}, 
then / NT) € H\A\] 



31 



The combinator can be defined using the time construct as follows: 

do A watching a = new stop, go in ( time A on go, 

always if stop else go, 
always if a then always stop) 

Proofs are routine, and have been omitted. Analogous to watching, we can 
define another construct do A while a, which keeps A going only as long as 
a holds. 

Example 25 do A trap a is similar to do .4 watching a. Semantically, an 
observation of do A trap a arises in the following way: A is executed in the 
interval [0,r]; a is not entailed in [0,r) and a is entailed at r. Process A is 
aborted after r, thus do A trap a imposes no restrictions on the behaviour of 
the system in (r, oo). This construct allows .4 to respond to a before getting 
terminated — also a may be generated by .4 (unlike in do A watching a, 
where A generating the a could result in an indeterminate program). As in 
the first, the behavior of this construct relies on the existence of well-defined 
first occurrences of a. Formally, 

W[do A trap a] = 

{/ e H\A\ I (Vr € dom(/))a £ * 2 (f(r))} 
U {/ € HObs | 3r e dom(/) 8 /*[0,r] g H{A\,a G ir 2 (/(r))} 



do A trap a = new stop, go in ( time A on go, 

always if stop else go, 
always if a then hence stop) 

l| ) [ 

A 



Time — > 

Fig. 7. Time diagram for S a A~{ A). 

Example 26 Using multiform time, we can write a construct to suspend a 
process and later activate it. This is similar to the familiar (control — Z,fg), 
and is illustrated in Figure 7. S a A 6 (.4) behaves like .4 until the first instant 
when a is entailed; when a is entailed .4 is suspended from then on (thus, the 



S a ). A is reactivated in the first time instant when b is entailed (thus, the A b ). 

S a A b (A) = new stop, go in ( time A on go, 

always if stop else go, 

first a then do (always stop) watching 6) 

Again proper behavior of this construct depends on the existence of "first" 
occurrences of a, 6. Repeated suspension-reactivation is done similarly: 

RS a Ab(A) = new stop, go in ( time A on go, 

always if stop else go, 

always if a then do (always stop) watching b) 



Thus, there is a general pattern of writing such constructs — one can always 
time A on go, and then precisely control the stop's and go's. 



4-4 Input-output behavior. 



Given a process Z, we can define its input-output behavior after a history /, 
with dom(/) = [0, r), as the i/o behavior of the Default cc process (Z after /)(0) 
Similarly, the i/o behavior after g with &om(g) = [0,5] is the i/o behavior of 
the Default cc process (Z after g)(0+). This leads us to the definition of de- 
terminacy. 

Definition 27 A process Z is called determinate if 

(V/ 6 Z) [dom(/) = [0,r) (Z after /)(0) is determinate, 
dom(/) = [0,r] => (Z after /)(0 + ) is determinate.] 

Similarly, the definition of A'-determinate for Hybrid cc processes is obtained 
by extending the definition for Default cc — we again note that determinate 
processes are A'-determinate for all variables X. 

Definition 28 A Hybrid cc process Z is X -determinate if for all f in Z 

- (V< € dom(/)) (Z after f[[0,t))(0) is X -determinate 

- (Vr 6 dom(/)) (Z after /r[0,r])(0 + ) is X -determinate 
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Determinacy detection algorithm. The determinacy detection algo- 
rithm for Default cc lifts to a determinacy detection algorithm for Hybrid cc. 

Given a Hybrid cc program P arising out of the syntax ; we associate two sets 
of Default cc processes P inst — the set of all possible instantaneous Default cc 
processes — and P cont — the set of all possible Default cc processes causing 
continuous evolution — that can arise in the evolution of P. We provide 
finite and conservative estimates of these sets — thus reducing determinacv 
detection of Hybrid cc to determinacy detection of Default cc. 



Process 


P 

J xnst 


Pcont 


c 


{c, true} 


{true} 


if c then A 


{if c then P \ P e A inst } U A inst 


A cont U {true} 


if c else A 


{if c else P | P € A inst } U A inst 


A cont U {true} 


(A U A 2 ) 


{(PuP2)\Pi€A i(inst) } 


{(PuP2)\Pi€ A i(cont) ) 


new A' in A 


{new X in P \ P e A inst } 


{new X in P \ P e A cont } 


hence A 


{(Pu-.-,P n )\Pi£A inst } 


{(Pu..-,P n )\PieA inst UA c » nt } 



where in the last case the Pi's are distinct. 



The above test is conservative but not exact — an exact test can be obtained 
by compiling Hybrid cc programs to finite Hybrid automata [20], and checking 
determinacy of the Default cc programs in the states. 



5 Operational Semantics and Correspondence Theorems 

In this section, we describe how Hybrid cc is realized computationally. We 
describe a formal operational semantics and relate it to the denotational se-. 
mantics presented above. The operational semantics forms the basis of our 
implementation, which we describe in the next section. 



5.1 Operational semantics 



The operational semantics for Hybrid cc is built on the operational semantics 
for Default cc. 

We assume that the program is operating in isolation — interaction with the 
environment can be represented as an observation and run in parallel with the 
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program. We use I\ A. . . . for multisets of programs; a{F) is defined as before 
— the tell tokens in f. 



Configurations can be point or interval configurations. A point configuration 
is a Default cc program that is executed instantaneously (at a real time in- 
stant) — all discrete changes happen at point states. This execution results 
in three pieces of information: the token b on quiescence, a token of the form 
init(a) that is derived from b and is the initial condition for the subsequent 
interval state, and finally the "continuation" — the program to be executed 
at subsequent times. 

Interval configurations are triples (a, T, A) and model continuous execution. 
a is the initial token, this is similar to the initial conditions in a differen- 
tial equation. T consists of the programs active in the interval configuration. 
Computation progresses only through the (continuous) evolution of the store 
as captured by the passage of time. In particular, the interval state is exited as 
soon as the status of any of the conditionals changes — one which always fired 
does not fire anymore, or one starts firing. A accumulates the "continuation". 

First, we describe transitions from point to interval configurations. — ► is the 
transition relation of Default cc, and 6(T') is the sub-multiset of programs of 
the form hence A in T'. 



r — > r 

r-Kr')init^(r')J) 



where cr(r) init = {init(a) | a(r') h 0 init(a)}. The computability condi- 
tions on ccs guarantee that cr(r)i n it can be represented by a single'token. 

In the interval configuration (a, I\ A) we are going to execute the program F 
"once", and make sure that the status of the conditionals remains constant 
throughout the interval (0,r). Condition 12 on continuous constraint systems, 
and the finiteness of the multisets ensures the existence of such an r > 0. The 
conditions on 3 A - in the ccs ensure that only one copy of the new variables 
needs to be made for the entire interval phase. 

The derivation relation is indexed by the "guessed output constraint" 6 (used 
to evaluate defaults as in the operational semantics of Default cc) and the 
length of the interval r. 
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a,cont(<7(r)) K C ' 

_ — — — — — —(then) 



(a,(I\if a' then 5), A) ^ 6 . r (a, (T. jB). A) 
a, cont(6) \f a' 

(a,(r,if a' else 5), A) ^ 6 , r (a, (I\ £). A) ( 0 
(a, (r, hence A), A) -^ 6 , r (a, (I\ A), (A, .4, hence A))(hence) 
(a, (I\ (.4, £)), A) m b , r (a, (I\ .4, B), A) (Par) 
(a,(r,new A' in A), A) -^ 6>r (a. (T, AfJ'/A']), A) (neu;) 

(F not free in a, A, A, T) 

The transition from interval to point configurations, is denned from -^i, r 
— verify that the guessed output constraint is achieved and verify that the 
residual conditionals were not enabled at any intermediate time. 

3b£lD3r>0 ( a ,r,A)-^ r (q,r,A') b = a(T') Pj^ 

(a,r,A)-^A' 

The output for any time t in this phase is 3- /'(a A cont(i)), where Y are the 
variables introduced by the operational semantics in this or a previous phase. 
T' l c T 4 verifies that the remaining conditionals in V were not enabled at any 
time during the open interval (0,r). 

a \c 4 Til 4 All 4 cb^a d±La 

Xr ' {T,A)l</ ' (if a then A) Ip (if a else A) J? 



5.2 Correspondence theorems 



The denotational semantics is correct for reasoning about the operational se- 
mantics. We first define OJPJ, the operational semantics defined from the 
transition relations given above. The operational semantics is generalized to 
work over constraints, rather than tokens, in the usual way. The definition 
essentially states that each phase of each observation must arise from the 
transition relation, similar to the definition for Default cc. 

Definition 29 0\P\ consists of all observations f € HObs of P. An obser- 
vation f of P satisfies the following : 

(i) //dom(/) = 0 i.e. f = e, then f is an observation of P. 
(ii) IfOe dom(/) then there is ave \ID\ such that 

- ^W/(0)) — >Z P' y^ v . 3-*{P*) = >n(/(0)),3- V = ^(/(O)). 

- P,*2(f(Q)) — C Q y^ v . tr(Q) = v. 
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(Hi) //dom(/) D {0}, let a = a(P') init . Then there is a v' e \ID\ such that- 

- (a,(*(P'),*i(/(0 + ))).p) ±^ v , r { a,Q>,P») with 3-a(Q') = Vl {f(0+)) 
and 3- v' = tt 2 (/(0 + )) and Q' 

- (a, (S(P'), tt 2 (/(0 + ))) ; g) ^v, r («, Q», P>") with a{Q") = v * and Q" I*'*' 

- JTi o / r [0, r) ana* tt 2 o / r [0, r) a7-e traces o/ </?e ccs. 

- /r[r. oo) is an observation of new Y' in P". 

Lemma 30 

finitely many phases} 

OlA t B] = 0[A]nO[B] 
0{if a then Aj = {e) U {/ e HObs | /(0) = (u, „), a € u => / € 0\A\, 

a € v (v,v) <Z OlA}} 
0[if a else A] = {e} U {/ € HObs | /(0) = («, v ), a £ v => / 6 O^J } 
Offnew A' in 41 = new x O[A] if 0{A] is X -determinate 

©[hence A] ={/€{/ € HObs | (V< > 0)/r[i,oo) € OffAj, 

/ /ias finitely many phases} 

PROOF . A proof sketch is provided in the appendix B. 

The proof proceeds by induction on the number of phases in the observation 
/. It involves a proof of correctness of the transition system; (1) in point (resp. 
interval) phases, the transition system captures the correct observations, and 
(2) the transition system passes the correct "continuation" to the succeeding 
interval (resp. point) phase. ° 



Now \ye can show the following theorem:- 

Theorem 31 If P is a Hybrid cc program which satisfies the X-determinacy 
condition for all X and f is a Hybrid cc observation with finitely many phase* 

then feniPl iff feOfP}. 



PROOF. A simple structural induction using the above lemma 30 yields the 
required result. 



Note that this theorem cannot give us full abstraction because of Zeno pro- 
cesses. For example, the above operational semantics run on a Hybrid cc pro- 
gram of a typical Zeno system — say, a bouncing ball, with a coefficient of 
restitution e < 1 — does not progress to and beyond the finite real limit point. 
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maintain is not definable using the other combinators of Hybrid cc. It satisfies 
the following laws: 



maintain = maintain, maintain 
maintain^ hence maintain 



Combined with the equational laws discussed earlier, the above laws ensure 
that a single top level occurrence of the combinator maintain suffices for 
variables that are not existentially quantified. For the programs we write in the 
concrete language, we leave this single top level occurrence of the combinator 
implicit. 



The continuous constraint system. The continuous constraint system 
we have built for our implementation separates the set of constraints that can 
be added to the store (the tell constraints) from the set whose validity can be 
inferred from the store (the ask constraints). The set of ask constraints is a 
proper superset of the set of tell constraints. This has been done to simplify 
the implementation, while retaining as much expressivity as possible. Also, 
our system is not complete with respect to the inferences that can be made 

- doing so would in fact entail solving arbitrary non-linear programming 
problems. 

The tell constraints can be of three different kinds: 

- Atoms, which are uninterpreted and simply added to the store — these are 
Gentzen style signals (see example 4). 

- Constraints involving continuously varying variables like dot(x,2) = 7 

we only allow one expression of the kind dot(x, n) on the left, and only 
expressions evaluating to constants on the right. 

- Some other expressions like inequalities, equations etc. 

Ask constraints include more general expressions, including multiplication etc. 
Complete details are given in the documentation that comes with the imple- 
mentation. 

The entailment relations are based on the entailment relations of example 17; 
augmented to allow for Gentzen style signals/constraints. In addition, the 
constraint system enforces a family of rules of the form 

dot(x, 1) = r,prev(x = s) h x = s 
a h init(a) 
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The first set of rules enforces the semantic content of existence of derivatives 
of real-valued functions — namely, left limit equals the value of the function 
at the point. The second set makes every variable right-continuous, this is 
implemented for convenience. Consider the following example, (contrast with 
example 21). 

Example 33 Consider the program P = maintain, x = 0, hence (dot(x, 1) 
= 1). The denotation of P consists of all observations / that satisfy ^(/(O)) H 
x = 0, (Vr 6 dom(/)) [^(/(r)) h dot(x, 1) = 1 A x = r]. 



The control constructs module. The interpreter works alternately in 
point phases and interval phases. It initially starts in a point phase with time 
t = 0. We briefly present some implementation details. 



The point rules. These are the Default cc rules. Any constraint is added to 
the store, and also wakes up any suspended asks. If a constraint c is determined 
to be valid by the constraint system, if c then A reduces to A as specified 
by the then rule. Otherwise it is added to the list of suspended asks. An else 
statement is always suspended initially, when there are no more active agents 
to process, it is processed as described below. To process new X in A, every 
occurrence of X in A is replaced by an internally generated symbol. Parallel 
composition is done by flattening lists of agents. 

After no more active agents are left (other than hence .4 agents), the inter- 
preter deals with the elses. For if a else A, there are two possibilities. Either 
a will be entailed by the final store and the agent stays suspended (in practice 
we delete it), or it will not be entailed, in which case A is added to the list 
of agents. The interpreter systematically searches these choices for each else, 
backtracking if a set of choices does not lead to a store that is consistent with 
the choices. As soon as a consistent store is obtained it is output as the output 
of the point phase. 

The init constraint entailed by the store is now passed to the interval phase 
along with the hence agents. 



The interval rules. In the interval phase, a Defa ult cc program is once again 
executed to obtain the store. At the same time, the length of the interval phase 
is determined as the longest interval during which the status of the asks in the 
Default cc program does not change. Since we want to have the largest possible 
interval to make the maximum amount of progress, we initially assume that 
the length of the interval will be infinity. Each rule is then implemented as 
follows. 



40 



If the interval store, with initial conditions from the previous point store entails 
a, then if a then B reduces to B. In addition, the constraint system computes 
an r for which this deduction is valid. The new interval length s the minimum 
of this r and the previous length, if a else B is implemented similar to the 
point rules. The constraint system provides the r for which a. constraint will 
not be entailed — this is the smallest r at which it will be entailed. For 
new A' in A, once again we replace the X by a new internally generated 
symbol. For hence A, both A and hence A are added to the list of agents 
for the next point phase. Parallel composition is implemented as a flattening 
of lists. 

Finally, the transition is made to the next point phase. Any suspended then's 
or else's are now examined for further limiting the extent of the interval phase 
(in the interpreter, this process is carried on simultaneously with the above 
steps). The limiting store at the end of the interval phase is passed as a prev 
constraint to the point phase along with the list of agents. Formally, this 
means that the transition rule from interval to point states of the operational 
semantics is changed to (notation is the same as in the operational semantics 
section): 



3BeID3r>0 ( Q ,r,A)^; r (q,r,A') b = a{T') ri b r - b 
(a, T, A) —— ► [/ r a A cont(6)] prev , A' 



where a prev = {prev(fc) | b € Base/,, ah b}. This change reflects the effect of 
the combinator maintain. 



Procedure calls and recursion. We have implemented a simple syntax 
for procedure calls in the interpreter — a call to p(A, B, C) is replaced by 
the body of p(A, Y, Z), with a textual substitution of the variables. We can 
implement recursive calls this way — note the recursion for parameter free 
procedures can be written in the basic syntax using hence . 



7 Hybrid cc — Programming Examples 

We now present a couple of programs to illustrate programming in Hybrid cc. 
7.1 Temperature Controller. 

We model a simple room heating system which consists of a furnace which 
supplies heat, and a controller which turns it on and off. The temperature 
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preter is seen below. Since the program runs forever, we aborted it after some 
time. The execution in the point and interval phases is displayed separately. 
For both phases of execution, the contents of the store are displayed. In addi- 
tion, for the interval phase, the interval is also displayed, and the continuous 
variables are displayed as polynomials in time. In the interval, time is always 
measured from the beginning of the interval, not from 0. 

I ?- hcc(controlled.furnace(2, 0.5, 30, 26, 26)). 
Time » o. 

Atoms : [furnace. on, switch. on] 
Variables : [dot (temp , 1)=2 ,temp=26] 

Time Interval is (0, 2.0) 
Atoms : [furnace. on] 
Variables : [temp=2*t+26] 

Time = 2.0. 

Atoms : [f urnace.of f ,switch.of f ] 
Variables : [dot (temp , 1)= -0.5,temp=30.0] 

Time Interval is (2.0, 10.0) 
Atoms : [f urnace.of f ] 
Variables : [temp= -0.5*t+30.0] 

Time = 10.0. 

Atoms : [furnace. on, switch.on] 
Variables : [dot (temp , 1 ) =2 , t emp=26 . 0] 

Time Interval is (10.0, 12.0) 
Atoms : [furnace. on] 
Variables [temp=2*t+26.0] 



7.2 A billiards table simulation 



We present a program modeling a simple billiards(pool) table with several 
balls. The table initially has several balls on it, with various velocities. The 
balls keep rolling in a straight line until they hit another ball or hit the edge 
of the table, or they come to a halt due to friction. 

Each ball is modeled by an agent ball (B, PosX, PosY, VelX, VelY), where 
B is the name of the ball, (PosX, PosY) is the initial position and (VelX, 
VelY) is the initial velocity. The initial configuration also gives the dimensions 
of the table — (xMax, yMax), the radius of the balls, the size of the pockets 
and the deceleration due to friction. It activates the agents for computing edge 
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collisions, ball-ball collisions and pocketing, 
initial.conf ig: : 

always {xMax = 150, yMax = 300, radius = 3, pocket = 7, fric = 1} 

ball(bl, 10, 10, 25, 25), 

ball(b2, 20, 11, -35, 55) , 

ball(b3, 80, 51, -15, 49), 

edge.collision, 

two. ball. collision , 

pocketing. 

The ball agent sets up the initial position and velocity. It also computes the 
direction of motion of the ball, and records it as cos 2 0, where 6 is the direction 
of movement. This is used to compute the effect of friction on each of the two 
components of the velocity. The constraint ball(B) asserts that B is a ball. 
The constraint change (B) is used to assert that ball B has had a collision. If 
there is no collision, then the ball continues rolling in its original direction, 
and its velocity decreases according to the deceleration due to friction. If there 
is a collision, the new direction is computed, and change in position is linked 
to the new velocity. The exception handler do . . . watching pocketed(B) 
allows us to handle pocketing of balls, a: b is an uninterpreted symbol, it is 
used here as a pairing construct. 

ball(B, PosX, PosY, VelX, VelY) : : 

{(B:pos:x) = PosX},{(B :pos :y) = PosY}, 

{(B:vel:x) = VelX}, {(B:vel:y) = VelY}, 

{dot(B:pos:x) = VelX}, {dot (B :pos : y) = VelY}, 

{(B: direction) = VelX*VelX/(VelX*VelX + VelY*VelY)}, 

always {ball(B)}, 

do hence [if change(B) else roll.ball(B) , 
if change (B) then 

[{dot(B:pos:x) = (B:vel:x)}, 
{dot(B:pos:y) = (B:vel:y)}, 
{(B: direction) = (B: vel :x)*(B : vel :x) / 
((B:vel:y)*(B:vel:y)+ 
(B:vel:x)*(B:vel:x))}]] 

watching pocketed(B) . 

roll.ball(B):: 

{dot (B: direct ion) = 0}, 
{dot(B:pos:x) = (B:vel:x)}, 
{dot(B:pos:y) = (B:vel:y)}, 
if (prev(B:vel:x) > 0) then 

{dot(B:vel:x) = -fric*sqrt (B : direction) } , 
if (prev(B:vel:x) < 0) then 

{dot(B:vel:x) = fric*sqrt (B : direction)} , 
if (prev(B:vel:x) > 0; prev(B : vel : x) < 0) else 
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{dot(B:vel:x) = 0}, 
if (prev(B:vel:y) > 0) then 

{dot(B:vel:y) = -f ric*sqrt ( 1 - (B : direction) )} , 
if (prev(B:vel:y) < 0) then 

{dot(B:vel:y) = fric*sqrt(l - (B : direction) )> , 
if (prev(B:vel:y) > 0 ;prev(B : vel : y ) < 0) else 

{dot(B:vel:y) = 0}] 

The edge collision agent just keeps checking if any ball has hit the edge — i.e. 
its distance from the edge is its radius. In that case, it reverses the appropriate 
component of the velocity, while retaining the other. The construct forall C do 
A is used here as a shorthand for parallel composition — for each instance of 
C, it creates an instance of A to be run in parallel with all the other instances. 

edge.collision: : 

always [forall ball(B) do 

[if (prev(B:pos :x) = radius; 

prev(B:pos:x) = xMax - radius) then 
({change (B)}, {(B:vel:x) = -prev(B : vel : x)} , 
{(B:vel:y) = prev(B : vel :y)>) , 
if (prev(B:pos:y) = radius; 

prev(B:pos:y) = yMax - radius) then 
({change (B)>, {(B:vel:y) = -prev(B : vel :y)}, 
{(B:vel:x) = prev(B : vel :x)»]] . 

The edge collision agent computes for each pair of balls if they are currently 
undergoing a collision, i.e. the distance between their positions is twice the 
radius. The ask (Bl 0< B2) uses the Prolog term ordering to make sure that 
this work is done only once for each pair of different balls. Now there are two 
cases. If the balls have the same x-coordinate, they simply exxhange their y 
velocities. Otherwise, we compute c = tan 0, the direction of the line joining 
their centers (the first case was necessary to deal with 0 = tt/2). Now by 
solving the equations of conservation of energy and momentum, we get the 
x-component of the impulse transmitted between them. The y-component is 
obtained by multiplying with c, since the transfer of impulse is along the radii 
(we assume frictionless collisions). This gives us the required velocities. Note 
that in true declarative programming, here we would have just stated the 
laws of conservation of energy and momentum. However, our constraint solver 
currently does not allow us to solve quadratic equations in the constraints, so 
we provided the solutions ourselves. 

two_ball_ collision: : 

always. [forall ball(Bl) do forall ball(B2) do 
if (Bl @< B2) then 

if ((prev(Bl:pos:x) - prev (B2 : pos : x) ) * 
(prev(Bl:pos:x) - prev(B2 :pos : x) ) 
+(prev(Bl:pos:y) - prev(B2:pos :y) )* 



(prev(Bl:pos:y) - prev(B2 : pos : y) ) = 4*radius*radius) 
then [{ change (Bl)}, {change (B2)} , compute. velocity (Bl ,B2)]] . 

compute_velocity(Bl ,B2) : : 

if (prev(Bl:pos:x) = prev(B2 :pos : x) ) then 
[{(Bl:vel:x) = prev(Bl : vel : x)} , 
{(B2:vel:x) = prev(B2 : vel : x)> , 
{(Bl:vel:y) = -prev(B2: vel :y)>, 
{(B2:vel:y) = -prev(Bl : vel : y)}] , 
if (prev(Bl:pos:x) = prev(B2 :pos :x) ) else 
[new c in new ix in 
[{c = (prev(Bl:pos:y) - prev(B2 :pos : y) )/ 

(prev(Blrposrx) - prev(B2 :pos :x) )> , 
{ix = (prev(B2:vel:x)-prev(Bl:vel:x)+ 

c* (prev (B2 : vel : y) -prev(Bl : vel : y) ) ) / ( l+c*c) > , 
{(Bl:vel:x) = prev(Bl : vel : x) + ix}, 
{(B2:vel:x) = prev (B2 : vel :x) - ix}, 
{(Bl:vel:y) = prev(Bl : vel :y) + c*ix}, 
{(B2:vel:y) = prev (B2 : vel :y) - c*ix}]] . 

Finally, the pocketing agent determines when any ball is going to fall into a 
pocket. 

pocketing: : 

hence [{halfyMax = yMax/2}, 
forall ball(B) do 

if (prev(B:pos:x)*prev(B:pos:x) 7.(0,0) 
+prev (B : pos : y ) *prev(B : pos : y ) 

= pocket*pocket ; 
prev(B:pos:x)*prev(B:pos:x) 7. (0 , yMax/2) 
+ (prev (B : pos : y ) -halfyMax) * (prev (B : pos : y ) -halfyMax) 

= pocket+pocket ; 
prev(B :pos : x) *prev (B :pos : x) 7, (0 , yMax) 
+ (prev (B : pos : y ) -yMax) * (prev (B : pos : y ) -yMax) 
■ pocket*pocket ; 

(prev(B:pos:x) - xMax) * (prev (B : pos : x) -xMax) 7.(xMax,0) 
+prev (B : pos : y ) *pr e v (B : pos : y ) 

9 pocket+pocket ; 
(prev (B : pos : x) -xMax) * (prev (B : pos : x) -xMax ) 7, (xMax , yMax/2) 

+(prev(B:pos:y)-halfyMax)*(prev(B:pos:y) -halfyMax) 
= pocket+pocket ; 

(prev (B :pos : x) -xMax) * (prev (B : pos : x) -xMax) 7. (xMax , yMax) 
+ (prev (B : pos : y) -yMax) * (prev (B : pos : y) -yMax) 
= pocket*pocket) 
then {pocketed (B)}] . 

We omit the trace of this program for brevity. 
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checking to restrict the use of program combinators. For a concrete example, 
recall the combinator first a then A used in programs earlier — this program 
reduces to .4 at the first time instant that a becomes true — if there is a 
well-defined notion of first occurrence of a. Now the denseness of the reals 
allows occurrences of a to exist without a :; first" occurrence — for example 
when a occurs in the interval (0,/). A type system can be used to encode this 
assumption on occurrences of the event a in the type of the program. 
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A Proof of Default cc Lemma 



Lemma 34 The relation — ►„ satisfies: 

Confluence: If A — >' v A' and A — >' v A" and there is no clash in variable 

names between the two derivations then there is a B such that A' B 

and A" — B. 

Monotonicity: A — ►* A' A,B — ►* A', B. 

Extensivity: A — r A' => cr(A') D a(A). 

Idempotence: A — »; A' ^„=> A,3-a(A') — ; A' -f-> v , where Y are 
the new variables introduced in the derivation. 

Thus, the relation — > v satisfies the characteristic properties of the transition 
relation of cc languages. 

Lemma 35 For all Default cc programs A and B, 
0\a\ = V\a\ 
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0{if a then 4j= {(u,i>) E DObs | a € v (v,v) G 0ff4j ; 

aeu=> (u,v) e 0{A\} 
Ofif a else .4] = {(«, i/) € DObs | a £ v => (w, r) € 0{A\) 
Ofnew A' in A] = new^O[Aj, e/OI^]) A - determinate 



PROOF. As indicated by lemma 34, the proof of the lemma follows extant 
proofs for languages in the cc paradigm. Detailed proofs for all cases can be 
found in [45]. Here, we merely sketch a couple of cases to expose the flavor of 
the proof and some salient features of Default cc. 

The case for parallel composition is described to show the similarity of the 
proof to the proof for cc languages. 

- Let (u,v) € OlA u A 2 }. Then u,A 1 ,A 2 — B and 3-a(B) = u. 
We show that (u,v) € OfAjJ. Let u,A t —+' v , A\ /-„,. UsinJ lemma 34, 

« Q <r(A[). Using lemma 34 again, u,A u A 2 >' v , A[,A 2 . Using confluence 

of — v, A\,A 2 — B. Using lemma 34, <r(4i) C cr(5). Thus 3-<j(A\) = 
u and we can deduce (u,v) € 0\A^. A symmetric argument shows that 
(u, v) e 0\A 2 l Thus, Q\A X , 4 2 J C Of^J n C?|[4 2 ]]. 

- Let (u,«) 6 OlAilnOiAil Then, u,A, — A\ and i-a^) = u; 

also, u,4 2 — C j4' 2 /-v, and 3-cr(4' 2 ) = u. Note that in general ►„ 

satisfies: 

A\ t^ v ,A' 2 ^ v ,ff(A\) = <y{A' 2 ) => A[,A' 2 -/-> v 
Thus, we deduce that u,A u A 2 — r, A[,A' 2 Since 3-<j(A\, A' 2 ) = u 

(the new variables in the two derivations are disjoint), (u,v) 6 OL4, 4,1! 
Tbu a ,OlA 1 ,A 2 ]DO[A l ]nOiA 2 ]. " 

Next, we handle the key elements of the proof for the case of new variables. 
We reproduce the definition of the denotation for new variables for conve- 
nience. We are simplifying the definition by using the fact that C?f.4j is A- 
determinate.O|new A in 4j = new A -0|[4]|, where 

- Define Z x = (J{(Z v ,v) C Z | Vu € Z v ,u D 3 x v =>u = v}. 

- new x Z ± U{(S,v) C DObs | 3v'[(v',v') € Z 1 ,3 x v = 3 x v',3 x S = 
3 X Z V >}}. 

Below, we sketch the proof that Ofnew A in A} C new x 0[A}. The key case 
of the proof is to show that (v,v) € OJnew X in 41 implies that (v,v) € 
new x O[Al 
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Let (v,v) e Ofnew A' in A\. Then, 3v' such that new A" in A, v — ^ 
A " v = 3 newX 3-v',v' = a{A"), where newX is the new variable intro- 

duced for A, and Y are the other new variables (apart from newX) introduced 
in the derivation. 

Let v" = [3-v')[X/newX]. Since 3 x v = 3 x v", it suffices to show: 

- (*>", v") e 0{A\. This is a simple fact about, renaming, and standard cc style 
proofs for the new A" in ... combinator show that (v",v") £ OlAj. 

- (V{w, v") e 0{A\) , it- D 3 x v" ^w = v". We note that from the monotonic- 
ity of the — ► . relation, and the fact that 3-v'[X/newX] = v", it suffices 
to show: 

(A, 3 x v") —+:, [x/newX] A"[X/newX] -f-^ v , [x/newX] 

v'[X/newX] = a(A"[X/neivX]) 

This follows from 

(A[newX/Xl 3 x v") — <, A" y^ v ,, v' = *{A") 

which in turn follows from (new X in A,v) — A" /— v,?/ = <j{A") 
since the X part of the information in v could not have played any role in 
the derivation, and 3 x v = 3aV. 



B Proofs of Hybrid cc Lemmas 



The following lemma captures the essence of the evolution in the point phases 
in Hybrid cc — the first consequence says that the correct Default cc obser- 
vation is captured in the point phase, and the next says that the correct 
"continuation" is passed to the interval phase. 

Lemma 36 Let W|rj satisfy the X-determinacy condition for all variables X. 

Let T >i F J-^> b) with Y being the new variables introduced by the transition 

system. Let f be such that dom(/) = {0},/(0) = (<r r <,6). Let 3-/ stand for 
the function such that dom(3-/) = {0}, 3-/(0) = (3-<7 r >, 3-6). \hen : 

- 3-/ e w[ri 

- Ifb = <r(r), H\T\ after 3-/ = WJnew Y in 6{T')} after 3-/ 

PROOF. The first proof is essentially a statement about Default cc — it 
follows by induction on the number of rules in Y — > 6 P. 
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The second proof follows from the following intermediate facts: 

- If b = a(T'), then HIT'} after / = W[*(F)1 after /. Proof is a routine 
structural induction on F'. 

- If b = cr(P) 5 then Hffr] after 3-/ = W[new Y in r'J after 3-/. Proof 
follows by induction on the number of transitions in T >: T' 

0 

The next lemma is the interval counterpart of the previous lemma — the first 
consequence says that the correct observation is captured in the interval phase, 
and the next says that the correct "continuation" is passed to the point phase. 

Lemma 37 Let (a,T,0) ^ r (a,F, A') Let P j(*(n,*). Let y be the 

new variables introduced in the transitions. Let f e HObs, dom(/) = [0, r) be 
such that: 



^(/(0))init=<M = 1,2 

fa A cont(cr(r / )), i = 1 
/' a A cont(6), i = 2 



(V0 < * < r)*,.(/(<)) = i 



Let 3~/ stand for the function dom(3-/) = dom(/ , ).(V0 < £ < r) (Vi = 
1,2) K(3-/(t)) = 3- *,(/(*))]. ™en 

- 3-/ e win 

- 7/6 = a(P) niTj after 3-/ = Wfnew Y in A'J 

PROOF. The proof has very similar structure to the proof of the previous 
lemma 36. This is because execution in the interval phase is in effect achieved 
by execution of a Default cc program. 

For the first item, first note that a structural induction on A' shows that: 

An induction on the number of the rules in the transition from T to V yields- 
( V( P )' 3 y 6) G 3-/ € HIT} follows. 

The second proof follows from the following intermediate facts: 

- If 6 = a(r'), then W[hence PJ after / = HfA'J. Proof is a routine struc- 
tural induction on P. 

- If b = <r(P), then «[rj after 3-/ = W[new Y in hence PJ after 3-/. 
Proof follows by induction on the number of rules in T — > 6 P. ^ 
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Lemma 38 

0{a} = {f e n\a\ | / has finitely many phases} 

0[if a then A} = {e} U {/ 6 HObs | /(0) = (u, v), a € u f € 0[A], 

0{it a else A] = {e}U {/ € HObs | /(0) = (ti, a g v =► / 6 0[.4J} 
OInew X in A] = new A -C?[Al if 0\A\ is X -determinate 
<?[hence A] = {/ € HObs | (V< > 0)/ f[t, oc) € OJAJ, 

/ has finitely many phases} 



PROOF. We prove by induction on the number of phases of / € HObs that 
for all programs A that satisfy the A'-determinacy condition: 



feO{a]^f€H[a] 
f 6 0(A, Bj <=> f e OlA\ n 0[B] 
f e 0[it a then A] f = e or /(0) = (u, v), a e u =j> / € 0[A], 

a e v (v,u) e C?[AJ 
/ € C?[if a else AJ<^/ = e or /(0) = («,t>),a g » / e OffAj 
/ € 0[new X in AJ«>/ € new^OfAj 

/ € Offhence A] <S> (V* > 0)/ r [t, oo) € 0[A] 



For the combinators from Default cc, the second part of lemma 36, attesting to 
the correctness of the continuations, allows us to use the inductive hypothesis 
on the remainder of /. 

For hence A, lemma 37 allows us to conclude that the operational and deno- 
tational semantics agree on the first interval phase of /. The second part of 
lemma 37, attesting to the correctness of the the continuations after the first 
interval phase of /, allows us to use the inductive hvpothesis on the remainder 
of/. 
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